Understanding Tables, Columns, Keys, and Relationships in Power BI

Course: Microsoft Power BI Training

Topic: Understanding Tables, Columns, Keys, and Relationships

Course Link: Microsoft Power BI Training at JustAcademy

Demo Link: Register for a Course Demo

JustAcademy Website: Visit JustAcademy

1. Introduction to Data Modeling in Power BI

Data modeling is one of the most important concepts in Power BI. It involves organizing data into tables, defining columns, identifying keys, and establishing relationships between tables so that information from different sources can be analyzed together.

In a real business environment, data is rarely stored in one perfectly organized table. Customer details may be stored in a Customers table, product information in a Products table, and transaction records in a Sales table. Power BI uses relationships to connect these tables and support accurate filtering, grouping, and calculations.

A well-designed data model makes reports easier to build, improves consistency, and helps users answer business questions without repeatedly combining all source data into one large table.

1.1 What Is Data Modeling?

Data modeling is the process of structuring data and defining how different pieces of information are connected. In Power BI, the data model contains tables, columns, measures, hierarchies, and relationships used by report visuals and calculations.

For example, a retail company may want to analyze sales by product category, customer city, and order date. The model can contain separate Products, Customers, Dates, and Sales tables. Relationships allow the report to analyze sales using information from these related tables.

1.2 Learning Objectives

• Understand tables and columns in a Power BI semantic model.
• Identify fact tables and dimension tables.
• Understand primary keys, foreign keys, candidate keys, and surrogate keys.
• Learn how relationships connect tables.
• Understand one-to-many, one-to-one, and many-to-many relationships.
• Learn cardinality and cross-filter direction.
• Create and manage relationships in Power BI Desktop.
• Understand active and inactive relationships.
• Design a simple star schema.
• Troubleshoot common modeling problems.

2. Understanding Tables in Power BI

2.1 What Is a Table?

A table is a structured collection of data organized into rows and columns. Each row represents a record, while each column represents a particular attribute or field of that record.

For example, a Customers table may store Customer ID, Customer Name, City, and Country. Each row represents one customer, and each column stores a different piece of information about that customer.

2.2 Example of a Customers Table

In this example:

• Each row represents one customer record.
• Customer ID identifies a customer.
• Customer Name stores the customer's name.
• City stores the customer's location.
• Country stores the country associated with the customer.

2.3 How Tables Enter Power BI

Tables can be imported from many supported data sources, including Excel files, CSV files, SQL databases, SharePoint, and other systems.

The general workflow is:

1. Open Power BI Desktop.
2. Select Home > Get Data.
3. Choose the required data source.
4. Connect to the source and select the required tables.
5. Select Transform Data if the data needs cleaning or shaping.
6. Review column names, data types, duplicate records, and missing values.
7. Select Close & Apply to load the prepared data.
8. Review the loaded tables in Model view.

2.4 Types of Tables in a Data Model

In analytical modeling, tables are commonly organized into fact tables and dimension tables.

2.5 Fact Tables

A fact table stores business events and measurable values. It often contains numeric columns such as Sales Amount, Quantity, Cost, Profit, or Discount, together with keys that identify related dimensions.

Example Sales table:

The Sales table records individual sales transactions. Customer ID, Product ID, and Date Key help connect each transaction to descriptive information in other tables.

2.6 Dimension Tables

A dimension table contains descriptive information about business entities. These attributes make it possible to analyze facts by category, location, product, customer, or time period.

Example Products table:

This table allows users to group sales by product name or category. The Product ID connects each product to the corresponding sales records.

2.7 Difference Between Fact and Dimension Tables

3. Understanding Columns in Power BI

3.1 What Is a Column?

A column is a field that stores one type of attribute across the rows of a table. For example, a Sales table may contain Order ID, Customer ID, Product ID, Quantity, Sales Amount, and Order Date.

Each column has a name and a data type. Its values can be used for filtering, sorting, calculations, grouping, and establishing relationships.

3.2 Common Column Types

3.3 Why Data Types Matter

Correct data types help Power BI interpret data accurately and apply suitable operations. A numeric column can be aggregated, while a text column is normally used for labels or categories.

Incorrect data types can lead to problems such as:

• Numbers being sorted alphabetically instead of numerically.
• Date calculations failing because dates are stored as text.
• Relationship creation problems caused by incompatible key data types.
• Unexpected totals caused by numeric values being interpreted incorrectly.
• Leading zeros disappearing from identifiers such as customer codes.

Identifiers do not always need numeric data types. For example, a Customer ID such as C001 should normally be stored as text. Even an identifier containing only digits may be better represented as text if it is a code rather than a quantity.

3.4 Changing Column Data Types

1. Open Power BI Desktop.
2. Select Home > Transform Data.
3. In Power Query Editor, select the required column.
4. Use the data type icon in the column header or the Transform tab.
5. Select the appropriate data type.
6. Check for conversion errors or unexpected values.
7. Select Close & Apply.

3.5 Calculated Columns vs Source Columns

A source column is provided by the original data source. A calculated column is generated from a formula or transformation.

For example, a source table may contain Quantity and Unit Price. A calculated column named Gross Sales can be created using the formula Quantity multiplied by Unit Price.

In Power Query, a custom column is calculated during data preparation. A DAX calculated column is defined within the model. The choice depends on whether the logic belongs in data preparation or model-level calculation.

4. Understanding Keys in Power BI

4.1 What Is a Key?

A key is a column or combination of columns used to identify records or connect related data. Keys are fundamental to relational modeling because they help identify unique entities and match records between tables.

For example, Customer ID can identify a customer in the Customers table and appear in the Sales table to show which customer made each purchase.

4.2 Primary Key

A primary key uniquely identifies each row in a table. Each primary key value must be unique within that table, and it should not be missing.

Example Customers table:

Customer ID acts as the primary key because each customer has a distinct identifier in this table.

4.3 Foreign Key

A foreign key is a column in one table that refers to a key in another table. It represents the connection between related records.

Example Sales table:

Customer ID is a foreign key in the Sales table because it refers to Customer ID in the Customers table. A customer can appear many times in the Sales table when that customer makes multiple purchases.

4.4 Candidate Key

A candidate key is a column, or a combination of columns, that can uniquely identify every row in a table. One candidate key is selected as the primary key in traditional relational database design.

For example, an employee table might contain Employee ID and a company-assigned unique Employee Number. If both fields uniquely identify each employee, both may be candidate keys.

4.5 Alternate Key

An alternate key is a candidate key that is not selected as the primary key. It still uniquely identifies a record in the table.

For example, if Employee ID is selected as the primary key and Employee Number is also unique, Employee Number may serve as an alternate key.

4.6 Composite Key

A composite key uses two or more columns together to identify a row uniquely. No single column may be unique by itself, but the combination is unique.

Example:

The combination of Student ID and Course ID could identify a student-course enrollment when each student can enroll only once in each course. Student ID alone is not unique in this table, and Course ID alone is not unique either.

Power BI model relationships generally connect one column in one table to one column in another table. When the source uses a composite key, you may need to create a suitable single-column key or redesign the model using a bridge table or another appropriate approach.

4.7 Surrogate Key

A surrogate key is an identifier created specifically for modeling rather than taken directly from the source system. It is often an integer assigned to each row in a dimension table.

For example, a Products table may receive Product Key values 1, 2, and 3 even if the source system uses text product codes. A surrogate key can be helpful when the source does not provide a suitable unique identifier or when dimension records need distinct internal keys.

In Power Query, an index column can be used to generate a surrogate key in appropriate scenarios. The resulting key must be mapped consistently to the related fact table, and the process must preserve the same entity-to-key assignments during refreshes. A simple index that can change with row ordering is not automatically a reliable permanent key.

4.8 Natural Key

A natural key is an identifier that already exists in the business or source system. Examples include a product code, an employee number, or a customer number.

Natural keys can be useful when they are unique and stable. However, source systems may reuse identifiers, change their formats, or contain duplicates, so they must be validated before use in a model.

4.9 Comparison of Key Types

5. Understanding Relationships in Power BI

5.1 What Is a Relationship?

A relationship connects two tables through columns that contain corresponding values. It allows Power BI to use information from one table to filter or analyze data in another table.

For example, a Customers table can be connected to a Sales table using Customer ID. When a report user selects a customer, the relationship allows the selection to filter the associated sales records.

5.2 Why Are Relationships Important?

• They allow data from multiple tables to be analyzed together.
• They enable filters and slicers to affect related tables.
• They support accurate aggregation when the model is designed correctly.
• They reduce the need to duplicate descriptive information across large transaction tables.
• They help organize a model into facts and dimensions.
• They make reports easier to maintain as new data is added.

5.3 Example of Related Tables

Consider two tables.

Customers

Sales

The Customer ID column connects the two tables. The Customers table has one row for each customer, while the Sales table may contain several rows for the same customer.

5.4 How Relationships Work

Power BI relationships provide a path for filter propagation. When a report visual or slicer filters a dimension table, the filter can flow through the relationship to related fact records, depending on the relationship's direction and status.

For example, selecting Asha Sharma in a Customers slicer can filter the Sales table to the transactions where Customer ID is C001. A sales measure can then aggregate the remaining transactions.

Relationships do not automatically guarantee data integrity. If the Sales table contains an unknown Customer ID, that value may not match a row in the Customers table. Such mismatches should be investigated during data preparation.

6. Types of Relationships in Power BI

6.1 One-to-Many Relationship (1:*)

A one-to-many relationship is the most common relationship type in a typical Power BI star schema. One row in the first table can relate to multiple rows in the second table.

Example: one customer can make many purchases.

The Customers table is on the one side because Customer ID is unique there. The Sales table is on the many side because Customer ID can appear repeatedly.

6.2 Many-to-One Relationship (*:1)

A many-to-one relationship describes the same basic pattern from the opposite direction. Multiple rows in one table correspond to one row in another table.

For example, many sales records can relate to one product record. In Power BI, the relationship may be displayed as many-to-one when viewed from the Sales table to the Products table.

6.3 One-to-One Relationship (1:1)

A one-to-one relationship means each value in one related column corresponds to at most one row on the other side, and the related values are unique on both sides.

For example, a Customer Details table might contain additional details for each customer, with exactly one row per Customer ID. A one-to-one relationship may be appropriate if the tables are intentionally separated and their keys are unique.

Before creating a one-to-one relationship, consider whether the tables should instead be combined. A one-to-one relationship is useful in specific modeling scenarios but is not automatically the best design.

6.4 Many-to-Many Relationship (*:*)

A many-to-many relationship allows duplicate values on both sides of a relationship. It can be useful for certain modeling requirements, but it needs careful design because filters and aggregations can behave in ways that are difficult to interpret.

Example: a salesperson may work in several regions, and each region may have several salespeople.

In a well-designed model, a bridge table containing Salesperson ID and Region ID can represent these assignments. This often provides clearer control over filtering than connecting two dimension tables directly with a many-to-many relationship.

6.5 Relationship Types Summary

7. Cardinality and Cross-Filter Direction

7.1 What Is Cardinality?

Cardinality describes how rows in one table relate to rows in another table. Power BI uses cardinality settings to represent one-to-many, many-to-one, one-to-one, and many-to-many relationships.

The one side of a one-to-many relationship must have unique values in the relationship column. If duplicate values appear on that side during refresh, the model may fail to refresh or the relationship may become invalid.

7.2 What Is Cross-Filter Direction?

Cross-filter direction controls how filters propagate between related tables.

Single-direction filtering is generally preferred for straightforward star schemas because it reduces ambiguity and makes filter behavior easier to understand. Bidirectional filtering should be used deliberately because complex relationship paths can create ambiguous results or unexpected filtering behavior.

7.3 Example of Filter Propagation

Suppose the model contains Products and Sales tables connected by Product ID.

1. A report user selects Electronics in a Product Category slicer.
2. The Products table is filtered to products in the Electronics category.
3. The relationship propagates the filter to matching rows in Sales.
4. A Sales Amount measure aggregates the remaining transactions.

The result is sales for products in the selected category, provided the relationship is active and the model's filter paths support the intended behavior.

8. Active and Inactive Relationships

8.1 Active Relationship

An active relationship is the default relationship used for filter propagation between the connected tables. In Model view, an active relationship is usually displayed as a solid line.

For example, the relationship between Orders[Order Date] and Dates[Date] may be active so that date slicers filter orders by their order date.

8.2 Inactive Relationship

An inactive relationship exists in the model but does not automatically propagate filters as the active relationship does. It is usually displayed as a dashed line in Model view.

Inactive relationships can be useful when two tables have multiple valid relationships between them. For example, an Orders table may contain Order Date and Ship Date. Both columns can connect to the same Dates table, but only one of those relationships can be active between the same pair of tables at a time in the usual model configuration.

8.3 Using an Inactive Relationship with DAX

An inactive relationship can be activated for a specific calculation with the DAX function USERELATIONSHIP.

Sales by Ship Date =
CALCULATE(
    SUM(Orders[Sales Amount]),
    USERELATIONSHIP(Orders[Ship Date], Dates[Date])
)

This example calculates sales using the Ship Date relationship during the measure's evaluation. The column names must match the actual model. The Dates table must have a suitable relationship to Orders[Ship Date], configured as inactive for this example.

9. Understanding the Star Schema

9.1 What Is a Star Schema?

A star schema is a common data-modeling design in which a central fact table connects to surrounding dimension tables. The model diagram resembles a star because the fact table sits in the center and dimension tables connect around it.

Star schemas are recommended for many Power BI analytical models because they separate measurable business events from the descriptive attributes used to analyze them.

9.2 Example Star Schema

                 Customers
                     |
                     |
Products --------- Sales --------- Dates
                     |
                     |
                  Regions

In this simplified model, Sales is the fact table. Customers, Products, Dates, and Regions are dimension tables that provide fields for filtering and grouping sales.

9.3 Benefits of a Star Schema

• Creates a clear separation between facts and descriptive dimensions.
• Makes relationships easier to understand.
• Supports intuitive slicers and report visuals.
• Helps users analyze measures by product, customer, region, and date.
• Can improve model usability and query performance when designed appropriately.
• Reduces unnecessary repetition of descriptive attributes in transaction data.

9.4 Fact Table Granularity

Granularity describes the level of detail represented by one row in a fact table. Before building relationships, decide what each row represents.

Examples include:

• One row per sales order line.
• One row per daily product inventory balance.
• One row per customer transaction.
• One row per product and month for sales targets.

Mixing different levels of detail in the same fact table can cause incorrect aggregations. A clear grain helps ensure that totals and relationships behave as expected.

10. Creating Relationships in Power BI Desktop

10.1 Method 1: Create a Relationship in Model View

1. Open Power BI Desktop and load at least two related tables.
2. Select Model view from the left navigation.
3. Locate the tables that need to be connected.
4. Drag the key column from one table onto the matching column in the other table, or use the relationship management dialog.
5. Review the cardinality setting.
6. Review the cross-filter direction.
7. Check whether the relationship should be active.
8. Confirm the relationship and inspect the model diagram.

10.2 Method 2: Use Manage Relationships

1. Open the Modeling tab.
2. Select Manage relationships.
3. Select New to create a relationship.
4. Choose the first table and its relationship column.
5. Choose the second table and the matching column.
6. Set cardinality and cross-filter direction as appropriate.
7. Choose whether the relationship should be active.
8. Select OK and confirm the relationship appears in the list and model diagram.

10.3 Automatic Relationship Detection

Power BI can attempt to detect relationships automatically when data is loaded or when the user chooses the relationship autodetection option. It uses information such as column names and data characteristics to identify possible matches.

Automatic detection is convenient, but it should not replace model validation. A relationship may be missed, incorrectly inferred, or created with settings that do not match the intended business logic.

10.4 Validate a Relationship

Before relying on a relationship, check the following:

• The columns contain the intended matching identifiers.
• The data types are compatible.
• The one-side column contains unique, nonblank key values.
• The many-side values match valid keys where required.
• The cardinality reflects the actual data.
• The filter direction supports the intended report behavior.
• The active relationship is the one that should be used by default.

11. Relationship Problems and How to Fix Them

11.1 Duplicate Values on the One Side

A one-to-many relationship requires unique values on the one side. If the intended key contains duplicates, Power BI may reject the relationship or fail during refresh if duplicates are introduced later.

Possible solutions:

• Investigate why the duplicate keys exist.
• Correct duplicate records when they are genuine data-quality errors.
• Create a separate dimension table with distinct valid keys if appropriate.
• Use a bridge table or redesign the model when the data truly represents a many-to-many relationship.

Do not remove duplicates automatically without checking their meaning. Duplicate rows may represent legitimate transactions or multiple assignments.

11.2 Incompatible Data Types

The columns used in a relationship should have compatible data types. For example, a Customer ID stored as text in one table and as a number in another can cause matching difficulties.

Use Power Query to standardize the data types and clean formatting differences. For identifiers, text is often appropriate even when the values contain only digits.

11.3 Unmatched Foreign Keys

A fact table may contain key values that do not exist in the related dimension table. For example, Sales might contain Customer ID C999 even though C999 is missing from Customers.

To resolve the problem:

1. Identify unmatched key values in the fact table.
2. Check whether the dimension record is missing from the source.
3. Correct invalid identifiers when possible.
4. Add valid missing dimension records when supported by the business process.
5. Consider an explicit Unknown or Not Available dimension member if appropriate.

11.4 Ambiguous Relationships

Ambiguity can occur when multiple active paths allow filters to travel between tables. This is more likely in complex models with several fact tables and bidirectional relationships.

Prefer a clear star schema with single-direction relationships where practical. Review active relationships and avoid introducing extra filter paths unless the model genuinely requires them.

11.5 Incorrect Totals in Reports

Incorrect totals can result from duplicate dimension keys, many-to-many relationships, mismatched grain, duplicated fact records, or unintended filter propagation.

Test totals at different levels of detail and compare them with the source data. Check whether each transaction is counted once and whether the selected dimensions filter the expected records.

12. Practical Project: Build a Sales Data Model

12.1 Project Objective

Create a simple Power BI data model with separate Customers, Products, Dates, and Sales tables. Establish relationships so that sales can be analyzed by customer, product category, and date.

12.2 Customers Table

12.3 Products Table

12.4 Sales Table

12.5 Relationships to Create

The Dates table should contain one row per date and a unique Date value. Ensure that Sales[Order Date] and Dates[Date] have compatible date values. If the Sales column includes a time portion, remove it or create a date-only column before relating it to the Dates table.

12.6 Build the Model

1. Import the Customers, Products, and Sales tables.
2. Create or import a Dates table with unique dates covering the sales period.
3. Check the data types of all relationship columns.
4. Confirm that each dimension key is unique.
5. Open Model view.
6. Create one-to-many relationships from Customers, Products, and Dates to Sales.
7. Use single-direction filtering from the dimensions to Sales unless the model requires a different design.
8. Create a report page with a Sales Amount card, a product category chart, and a customer city slicer.
9. Verify that selecting a category, city, or date filters the sales correctly.

12.7 Example DAX Measure

After the model is created, add a measure to calculate total sales:

Total Sales = SUM(Sales[Sales Amount])

Place Total Sales in a card visual. Add Product Category to a chart axis and Customer City to a slicer. The relationships allow the dimension fields to filter the Sales table and affect the measure.

12.8 Project Validation Checklist

• Customer ID is unique in Customers.
• Product ID is unique in Products.
• Date is unique in the Dates table.
• Sales may contain repeated Customer IDs and Product IDs.
• Relationship columns have compatible data types.
• Relationships have the intended cardinality and direction.
• Total Sales matches the sum of the source sales amounts.
• Report filters produce expected results.

13. Best Practices for Tables, Columns, Keys, and Relationships

• Use a clear model structure: Separate facts from descriptive dimensions when appropriate.
• Define the grain: Decide what one row represents in each fact table.
• Choose reliable keys: Prefer identifiers that are unique, stable, and meaningful for the relationship.
• Validate uniqueness: Ensure the one-side key contains no duplicates or unintended blanks.
• Standardize data types: Make relationship columns compatible before creating relationships.
• Keep descriptive attributes in dimensions: Use dimensions for filtering and grouping, and facts for measurements.
• Prefer star-schema relationships: Use one-to-many relationships from dimensions to facts when appropriate.
• Use single-direction filtering by default: Introduce bidirectional filtering only when the required behavior is understood.
• Do not remove duplicates blindly: Understand whether repeated values are data errors or legitimate business records.
• Validate unmatched keys: Investigate fact records that do not match a dimension.
• Use meaningful names: Give tables and columns clear, business-friendly names.
• Test report behavior: Check that slicers, totals, and visuals respond correctly to relationships.

14. Frequently Asked Interview Questions and Answers

Q1. What is a table in Power BI?

A table is a structured collection of records arranged in rows and columns. It stores information about business entities, transactions, or other data used in the model.

Q2. What is a column?

A column is a field that stores a particular attribute for the rows in a table, such as Customer Name, Order Date, Quantity, or Sales Amount.

Q3. What is a primary key?

A primary key uniquely identifies each row in a table. Its values should be unique and nonblank.

Q4. What is a foreign key?

A foreign key is a field that refers to a key in another table. It allows related records to be connected.

Q5. What is the difference between a primary key and a foreign key?

A primary key identifies a row uniquely in its own table, while a foreign key stores a reference to a related key in another table and can contain repeated values.

Q6. What is a composite key?

A composite key combines two or more columns to uniquely identify a record when no single column is sufficient.

Q7. What is a surrogate key?

A surrogate key is a generated identifier created for data modeling. It can be useful when a source system does not provide a suitable unique key, provided the key assignment is maintained consistently.

Q8. What is a relationship in Power BI?

A relationship connects columns in two tables and enables filters to propagate between related tables for analysis.

Q9. What is cardinality?

Cardinality describes how rows in one table relate to rows in another table. Common types include one-to-many, many-to-one, one-to-one, and many-to-many.

Q10. What is the most common relationship type in Power BI?

One-to-many is common in star-schema models, where one dimension record can relate to multiple fact records.

Q11. What is the difference between a fact table and a dimension table?

A fact table stores business events and measurable values, while a dimension table stores descriptive attributes used to filter, group, and categorize those facts.

Q12. What is a star schema?

A star schema is a modeling design with a central fact table connected to surrounding dimension tables. It supports clear and intuitive analytical reporting.

Q13. What is cross-filter direction?

Cross-filter direction determines how filters propagate across a relationship. The common options are Single and Both.

Q14. What is the difference between active and inactive relationships?

An active relationship participates in default filter propagation. An inactive relationship remains available in the model but generally must be activated for a particular calculation, often through DAX.

Q15. Why might Power BI reject a relationship?

Common causes include duplicate values on the one side, incompatible data types, an incorrect column selection, or data that does not meet the intended cardinality.

Q16. Can a foreign key contain duplicate values?

Yes. In a one-to-many relationship, the foreign key on the many side commonly contains repeated values because multiple fact records can refer to the same dimension record.

Q17. What happens when a fact table contains an unmatched foreign key?

The unmatched value does not correspond to a dimension row. It can cause records to appear under a blank or unmatched grouping in some analyses. The data should be investigated and handled according to business requirements.

Q18. Why are single-direction relationships often recommended?

They provide predictable filter flow from dimensions to facts and reduce the risk of ambiguous filter paths in complex models.

Q19. When should a bridge table be used?

A bridge table is useful when representing associations in which multiple records on one side can relate to multiple records on the other side, such as salespeople assigned to multiple regions.

Q20. How do you validate a Power BI data model?

Check key uniqueness, data types, relationship cardinality, filter direction, unmatched keys, fact-table grain, and the accuracy of report totals.

15. Practice Exercises

Exercise 1: Identify Table Types

Consider a model containing Customers, Products, Sales, and Dates. Identify which tables are dimensions and which table is the fact table. Explain why.

Exercise 2: Identify Keys

In a Sales table, identify a suitable primary key and the foreign keys needed to connect it to Customers and Products. Explain why Customer ID can repeat in Sales.

Exercise 3: Design Relationships

Create a model in which each customer can make many purchases and each product can appear in many sales transactions. Identify the one side and many side of each relationship.

Exercise 4: Diagnose Duplicates

A relationship cannot be created because Customer ID contains duplicates in the Customers table. List the checks you would perform before deciding whether to remove duplicates or redesign the model.

Exercise 5: Active and Inactive Relationships

An Orders table contains Order Date and Delivery Date. Explain how you could analyze orders by each date using a Dates table and appropriate relationships.

Exercise 6: Star Schema Design

Design a star schema for a retail company that needs to analyze sales by product, customer, region, and date. Identify the fact table, dimension tables, keys, and relationship types.

16. Quick Revision Checklist

• Understand tables, rows, and columns.
• Distinguish fact tables from dimension tables.
• Understand primary, foreign, candidate, alternate, composite, natural, and surrogate keys.
• Know why keys must be checked for uniqueness and data quality.
• Understand how relationships connect tables.
• Recognize one-to-many, many-to-one, one-to-one, and many-to-many relationships.
• Understand cardinality and cross-filter direction.
• Distinguish active relationships from inactive relationships.
• Understand how a star schema supports analytical reporting.
• Know how to create and validate relationships in Model view.
• Check data types, duplicates, and unmatched keys.
• Validate report totals and filter behavior before publishing a report.

17. Conclusion

Tables, columns, keys, and relationships form the foundation of a reliable Power BI data model. Tables organize information, columns describe attributes, keys identify and connect records, and relationships allow filters and calculations to work across multiple tables.

By understanding fact and dimension tables, choosing suitable keys, and designing relationships carefully, analysts can create models that are easier to understand, maintain, and use for business reporting. A clear star schema, consistent data types, validated keys, and well-tested relationships help produce more trustworthy analytical results.

18. Additional Learning Resources

• Microsoft Learn: Understand Model Relationships in Power BI
• Microsoft Learn: Create and Manage Relationships
• Microsoft Learn: Understand Star Schema and Its Importance
• Microsoft Learn: Power BI Documentation
• Microsoft Power BI Training at JustAcademy
• Register for a JustAcademy Course Demo
• Visit the JustAcademy Website